Summary

This PR adds a comprehensive edge-case test suite (test/test_diameter_edge_cases.jl) for the weighted diameter algorithm introduced in JuliaGraphs#495. It includes 50 targeted test cases and one bug report found through systematic testing.

Test results: 180 pass, 1 fail

The 1 failure is an intentional test that demonstrates a bug (see below).

Bug Found: Asymmetric Weight Matrix on Undirected Graphs

Description

_diameter_weighted_undirected produces wrong results when the weight matrix is not symmetric (distmx[i,j] != distmx[j,i]).

Minimal reproducer

g = path_graph(4)  # undirected: 1-2-3-4
distmx = [0.0 1.0 Inf Inf;
           5.0 0.0 1.0 Inf;
           Inf 5.0 0.0 1.0;
           Inf Inf 5.0 0.0]

diameter(g, distmx)                                     # => 5.0  (WRONG)
maximum(eccentricity(g, vertices(g), distmx))           # => 15.0 (correct)

Root cause analysis

The iFUB stopping condition at src/distance.jl:330:

lb >= 2 * d_prev && break

relies on the bound: for any unprocessed vertex v with d(hub, v) ≤ d_prev, the eccentricity satisfies ecc(v) ≤ 2 * d_prev. This comes from the triangle inequality:

d(v, w) ≤ d(v, hub) + d(hub, w) ≤ d_prev + d_prev = 2 * d_prev

The problem: the algorithm only computes d(hub, v) (forward Dijkstra from hub), but the bound requires d(v, hub) (the reverse direction). For undirected graphs with symmetric weights, d(v, hub) = d(hub, v), so the bound holds. But when distmx[i,j] ≠ distmx[j,i], the two distances diverge and the bound becomes invalid.

Detailed trace of the bug

Hub = vertex 2 (highest degree in path_graph(4))

Dijkstra from hub=2:
  d(hub→1) = 5.0,  d(hub→3) = 1.0,  d(hub→4) = 2.0
  → lb = 5.0
  → Fringes: d=5.0 → [v=1],  d=2.0 → [v=4],  d=1.0 → [v=3]

Processing outermost fringe d_i=5.0, d_prev=2.0:
  Dijkstra from v=1: ecc(1) = 3.0  →  lb = max(5.0, 3.0) = 5.0
  Check: lb=5.0 ≥ 2*d_prev=4.0?  YES → BREAK!

But vertex 4 (in fringe d=2.0, never processed) has ecc(4) = 15.0!
  d(hub→4) = 2.0 (forward, what the algorithm sees)
  d(4→hub) = 10.0 (backward, what the bound needs: 4→3→2 costs 5+5)

Impact

• Failure rate: ~77% with random asymmetric weights on undirected graphs (tested on 3000 random graphs)
• Regression: the old code maximum(eccentricity(g, distmx)) handled this correctly
• No impact on symmetric weights: 7000+ random tests with symmetric weight matrices all pass
• No impact on directed graphs: the directed algorithm (_diameter_weighted_directed) correctly tracks both forward and backward distances via separate fringes, so it handles asymmetric weights properly

Possible fixes

1. Symmetrize on entry: distmx = (distmx + distmx') / 2 — changes semantics
2. Use the directed algorithm for undirected graphs when distmx ≠ distmx' — correct but slower
3. Track backward distances too in the undirected algorithm (like the directed one does) — most robust
4. Document the restriction that distmx must be symmetric for undirected graphs — least code change

Minor observation: >= vs > in breaking condition

• Undirected (distance.jl:330): lb >= 2 * d_prev
• Directed (distance.jl:290): lb > 2 * d_prev

The directed > is slightly more conservative (processes one extra fringe). Testing confirms both >= and > produce correct results for directed graphs (1948 additional tests), so this is just a minor inefficiency, not a correctness bug. Using >= for both would be fine.

Test cases included (50 tests, 181 assertions)

Test plan

• Run test/test_diameter_edge_cases.jl — 180 pass, 1 expected fail (asymmetric-weight bug)
• Run existing test/distance.jl — all 280 tests pass
• Stress tested 7000+ random graphs with symmetric weights — all pass
• Stress tested 1948 directed graphs with >= vs > condition — both correct

🤖 Generated with Claude Code